home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / program / progem.lzh / wind9.prf < prev   
Text File  |  1987-06-23  |  21KB  |  482 lines
  1. .!****************************************************************************
  2. .! 
  3. .! ANTIC PUBLISHING INC., COPYRIGHT 1985.  REPRINTED BY PERMISSION.
  4. .!
  5. .! ** Professional GEM ** by Tim Oren
  6. .!
  7. .! Proff File by ST enthusiasts at
  8. .! Case Western Reserve University
  9. .! Cleveland, Ohio
  10. .! uucp : decvax!cwruecmp!bammi
  11. .! csnet: bammi@case
  12. .! arpa : bammi%case@csnet-relay
  13. .! compuserve: 71515,155
  14. .!
  15. .!****************************************************************************
  16. .!
  17. .!
  18. .!****************************************************************************
  19. .!
  20. .!            Begin Part 9
  21. .!
  22. .!****************************************************************************
  23. .!
  24. .PART IX VDI Graphics: Lines and Solids
  25. .PP
  26. This  issue  of ST PRO GEM is the first in a  series  of  two
  27. which  will explore the fundamentals of VDI graphics  output.   In
  28. this installment, we will take a look at the commands necessary to
  29. output simple graphics such as lines,  squares and circles as well
  30. as  more complex figures such as polygons.   The following episode
  31. will  take a first look at graphics text output,  with an emphasis
  32. on  ways  to  optimize its drawing speed.   It will  also  include
  33. another  installment  of ONLINE Feedback.   As usual,  there is  a
  34. download  with  this column.   You should find it under  the  name
  35. GEMCL9.C in DL3 of ATARI16 (PCS-58).
  36. .SH A  BIT  OF HISTORY
  37. One  of  the reasons that the VDI can  be  confusing  is  that
  38. drawing anything at all,  even a simple line,  can involve setting
  39. around four different VDI parameters before making the draw  call!
  40. (Given  the state of the GEM documents,  just FINDING them can  be
  41. fun!)  Looking backwards a bit sheds some light on why the VDI  is
  42. structured this way,  and also gives us a framework for organizing
  43. a discussion of graphics output.
  44. .PP
  45. The GEM VDI closely follows the so-called GKS standard, which
  46. defines  capabilities  and calling sequences  for  a  standardized
  47. graphic  input/output system.   GKS is itself an evolution from an
  48. early system called "Core".   Both of these standards were born in
  49. the  days  when  pen plotters,  vectored  graphics  displays,  and
  50. minicomputers  were  the  latest items.   So,  if you  wonder  why
  51. setting  the drawing pen color is a separate command,  just  think
  52. back  a  few  years when it actually meant  what  it  says!   (The
  53. cynical   may   choose   instead  to  ponder   the   benefits   of
  54. standardization.)
  55. .PP
  56. When  doing  VDI  output,  it helps if you pretend  that  the
  57. display screen really is a plotter or some other separate  device,
  58. which  has  its own internal parameters which you can set  up  and
  59. read  back.   The class of VDI commands called Attribute Functions
  60. let  you set the parameters.   Output Functions cause the "device"
  61. to  actually  draw  someone once it is  configured.   The  Inquire
  62. Functions let you read back the parameters if necessary.
  63. .PP
  64. There  are two parameters which are relevant no  matter  what
  65. type of object you are trying to draw.   They are the writing mode
  66. and  the clipping rectangle.   The writing mode is similar to that
  67. discussed in the column on raster operations.   It determines what
  68. effect the figure you are drawing will have on data already on the
  69. screen.  The writing mode is set with the call:
  70. .FB vswr_mode()
  71. vswr_mode(vdi_handle, mode);
  72. .FE
  73. Vdi_handle,  here  and  below,  is the  handle  obtained  from
  74. graf_handle at the beginning of the program.  Mode is a word which
  75. may be one of:
  76. .sp 1
  77. .in +8
  78. 1 - Replace Mode
  79. .br
  80. 2 - Transparent Mode
  81. .br
  82. 3 - XOR mode
  83. .br
  84. 4 - Reverse Transparent Mode
  85. .in -8
  86. .PP
  87. In  replace mode,  whatever is on the screen is  overwritten.
  88. If  you are writing characters,  this means the background of each
  89. character cell will be erased.
  90. .PP
  91. In  transparent  mode,  only  the pixels directly  under  the
  92. "positive"  part  of the image,  that is,  where 1-bits are  being
  93. written, will be changed.  When writing characters, the background
  94. of the cell will be left intact.
  95. .PP
  96. In XOR mode,  an exclusive or is performed between the screen
  97. contents and what is being written.   The effect is to reverse the
  98. image under areas where a 1-bit occurs.
  99. .PP
  100. Reverse transparent is like transparent,  but with a "reverse
  101. color  scheme".   That  is,  only  places where a 0-bit is  to  be
  102. put   are  changed  to  the  current  writing  color.    When  you
  103. write  characters in reverse transparent (over white),  the effect
  104. is reverse video.
  105. .PP
  106. The  other  common parameter is the clipping  rectangle.   It
  107. defines the area on the screen where the VDI is permitted to draw.
  108. Any output which would fall outside of this area is ignored; it is
  109. effectively a null operation.   The clip rectangle is set with the
  110. call:
  111. .FB vs_clip()
  112. vs_clip(vdi_handle, flag, pxy);
  113. .FE
  114. Pxy is a four-word array.   Pxy[0] and pxy[1] are the X  and  Y
  115. screen coordinates,  respectively,  of one corner of your clipping
  116. rectangle.    Pxy[2]  and  pxy[3]  are  the  coordinates  of   the
  117. diagonally opposite corner of the rectangle.   (When working  with
  118. the  AES,  use  of  a  GRECT to define  the  clip  is  often  more
  119. convenient.  The routine set_clip() in the download does this.)
  120. .PP
  121. Flag is set to TRUE if clipping is to be used.  If you set it
  122. to  FALSE,  the  entire  screen is assumed to be fair  game.
  123. .PP
  124. Normally,  you should walk the rectangle list for the current
  125. window to obtain your clipping rectangles.  (See ST PRO GEM #2 for
  126. more details.)  However, turning off the clip speeds up all output
  127. operations,  particularly text.  You may do this ONLY when you are
  128. absolutely certain that the figure you are drawing will not extend
  129. out of the top-most window, or out of a dialog.
  130. .SH THE LINE FORMS ON THE LEFT
  131. The  VDI  line  drawing  operations  include  polyline,  arc,
  132. elliptical  arc,  and rounded rectangle.   I'll first look at  the
  133. Attribute Functions for line drawing,  then go through the drawing
  134. primitives themselves.
  135. .PP
  136. The  most  common used line attributes are color  and  width.
  137. The color is set with:
  138. .FB vsl_color()
  139. vsl_color(vdi_handle, color);
  140. .FE
  141. where color is one of the standard VDI color  indices,  ranging
  142. from  zero to 15.   (As discussed in column #6,  the  color  which
  143. actually appears will depend on the pallette setting of your ST.)
  144. .PP
  145. The  line width may only be set to ODD positive  values,  for
  146. reasons  of  symmetry.   If you try to set an even value,  the VDI
  147. will take the next lower odd value.  The call is:
  148. .FB vsl_width()
  149. vsl_width(vdi_handle, width);
  150. .FE
  151. The  two  less  used line parameters are the  end  style  and
  152. pattern.   With  the  end style you can cause the output  line  to
  153. have rounded ends or arrowhead ends.  The call is:
  154. .FB vsl_ends()
  155. vsl_ends(vdi_handle, begin_style, end_style);
  156. .FE
  157. Begin_style  and end_style are each words which  may  have  the
  158. values zero for square ends (the default),  one for arrowed  ends,
  159. or  two  for  rounded ends.   They determine the  styles  for  the
  160. starting and finishing ends of the line, respectively.
  161. .PP
  162. The line pattern attribute can select dotted or dashed  lines
  163. as  well  as more complicated patterns.   Before  continuing,  you
  164. should  note one warning:  VDI line output DOES NOT compensate for
  165. pixel aspect ratio.  That is, the dashes on a line will look twice
  166. as long drawn vertically on a medium-res ST screen as they do when
  167. drawn horizontally.  The command for setting the pattern is:
  168. .FB vsl_type()
  169. vsl_type(vdi_handle, style);
  170. .FE
  171. Style  is  a word with a value between 1  and  7.   The  styles
  172. selected are:
  173. .sp 1
  174. .in +8
  175. 1 - Solid (the default)
  176. .br
  177. 2 - Long Dash
  178. .br
  179. 3 - Dot
  180. .br
  181. 4 - Dash, Dot
  182. .br
  183. 5 - Dash
  184. .br
  185. 6 - Dash, Dot, Dot
  186. .br
  187. 7 - (User defined style)
  188. .in -8
  189. .PP
  190. The  user  defined  style is determined  by  a  16-bit  pattern
  191. supplied  by the application.   A one bit in the pattern  turns  a
  192. pixel on, a zero bit leaves it off.  The pattern is cycled through
  193. repeatedly,  using the high bit first.  To use a custom style, you
  194. must make the call:
  195. .FB vsl_udsty()
  196. vsl_udsty(vdi_handle, pattern);
  197. .FE
  198. before doing vsl_type().
  199. .PP
  200. As  I  mentioned  above,   the  line  type  Output  Functions
  201. available are polyline,  circular and ellliptical arc, and rounded
  202. rectangle.   Each  has  its own calling sequence